\documentclass{article}
\usepackage[margin=4cm]{geometry}
\usepackage[parfill]{parskip}
\usepackage{lettrine}
\usepackage{titlepic}
\usepackage{graphicx}
\usepackage{appendix}
\usepackage{graphicx} % Allows including images
\usepackage{booktabs} % Allows the use of \toprule, \midrule and \bottomrule in tables
\usepackage{url}
\usepackage{listings}



%\textwidth = 390pt

\title{Honeynet As A Service}
\author{Hanieh Bagheri, Todor Yakimov}
\date{\today}

\begin{document}
\maketitle

\begin{abstract}
With many advances in network threats, additional tiers of security are needed apart from the common security tools, such as firewalls and Intrusion Detection Systems(IDSes). One such tier can be using honeynets to obtain some information about the existing security threats in a network. Although original honeynets were designed to run on real hardware machines, it is more efficient and more secure to run honeypots on top of virtual machines. However, deploying honeynets is usually a hard and time-consuming process and the deployed honeynet would be hard to maintain. In this research, we are interested in investigating the possibility of providing honeynet as a service, in order to make deployment of honeynets more convenient. An appropriate architecture for this purpose will be proposed and a proof-of-concept model will be implemented. 
\end{abstract}

\section{Introduction}

With many advances in network threats, additional tiers of security are needed apart from the common security tools, such as firewalls and IDSes. One such tier can be using honeynets to gain more information about the existing security threats in a network. In their essence, honeynets are designed to gather traces about the hackers that are capable of breaking into the network. In fact, the value of a honeynet lies in being probed, attacked, or compromised \cite{Spitzner}. Providing emulated services or using real (and vulnerable) applications, a honeypot is able to deceive attackers to assume they are attacking and damaging the production servers. In this way, the malicious behavior can be detected, analyzed and captured, and the results can be used to improve the security of the network. Although honeynets play an important role in improving the security of a network, we should keep in mind that they are not a replacement for other security tiers, such as security best practices, security policies, firewalls, IDSes and patch management\cite{Hoepers}.

One of the advantages of using honeynets is that it deals with suspicious and potentially malicious traffic. So compared to IDSes, it has to analyze less data and the provided information about the attackers are more valuable.  Another advantage of a honeynet is capability of discovering new malwares. While monitoring an attacker's behavior, a honeynet should be able to capture the used malware for further analysis.

Although honeynets are very useful for improving the security of a network, there are some disadvantages in using them: a honeynet can be a potential risk for the network, if it is not administrated well. It also can be hard and time-consuming to maintain.

The original honeynets were designed to be implemented on physical machines. However, if an attacker accesses a honeynet node and successfully exploits the existing vulnerabilities, recovering that machine might be hard and time-consuming. With advances in virtualization technologies, some approaches are proposed to run honeynet software on virtual machines (VM) rather than the real hardware. In this way, less hardware resources are needed. Moreover, in case of being exploited, the honeynet node can be easily recovered.

\subsection{Research Objective}
In this research, we are interested in verifying the possibility of implementing a honeynet on a cloud environment. In this way, we would be able to offer honeynets as a service to likely customers. We expect this kind of service make deploying honeynets easy, fast, cheap and more convenient to maintain. From the point of view of the service provider, the suggested model should be scalable, managable and economical. The goal of this research is proposing an architecture that satisfies both the customer's and service provider's requirements.


\subsection{Research Questions}
This project is mainly aimed to answer the following question:

\indent \emph{What is an appropriate architecture for providing honeynet as a service? }
\\
\\
The sub-questions that will be answered in this report will be:
\begin{itemize}
 	\item Is it feasible to offer honeynet as a service?
	\item What are the requirements?
	\item What components are needed?
	\item How can it be best implemented?
\end{itemize}

\subsection{Outline}
The previous works related to our research are discussed in Section \ref{sec:background}. In Section \ref{sec:design}, we will describe the features of an ideal model to provide honeynet as a service. Then, we will explain about the proposed architecture and its essential components. In section \ref{sec:implementation}, a proof-of-concept implementation will be described, followed by the conclusion of this report in Section \ref{sec:conclusion}.


\section{Background Works}
\label{sec:background}
\subsection{Low-interaction vs. High-interaction Honeypots}
\label{sec:highlow}
In terms of level of interaction between attackers and the system, there  are two types of honeypots: low-Interaction honeypots and high-interaction honeypots.

A low-interaction honeypot only allows the attacker to have a limited interaction with the system. It emulates some services and systems to interact with the attackers and reacts to malicious activities by running some scripts. As a result, a low-interaction honeypot is not vulnerable and cannot be infected by the attacker \cite{survey}. Low-interaction honeypots usually use vulnerability databases and also signature databases to detect malicious behaviors  Then, they decode or emulate the used shellcode to derive the malware URL and download the corresponding malware. This model needs to update the honeynet databases regularly.

The most well-known members of low-interaction honeypots family are honeyd and Nepenthes. Honeyd is a small daemon, which can create multiple virtual honeypots on a single machine. Different services like FTP, HTTP and SMTP can be emulated using honeyd. Honeyd \footnote{www.honeyd.org/faq.php, retrieved on March 30, 2013} can also emulate the IP stacks for various operating systems by responding to Nmap and Xprobe packets. Nepenthes \cite{survey} is another low-interaction honeypot, which is used for malware collection. It passively emulates known Windows vulnerabilities and downloads the payload when the attacker tries to exploit the vulnerability. Honeytrap and Kojoney are other examples of low-interaction honeypots.

High-interaction honeypots use real vulnerable operating systems and applications. What we call honeynet is actually a network of high-interaction honeypots. High-interaction honeypots provide us with more details about the attacker's activities. Since high-interaction honeypots are nothing, but a vulnerable system, we do not need any extra tool as the honeypot. We just need some data collection tools, such as Sebek\footnote{https://projects.honeynet.org/sebek/}. Sebek is a kernel module, which can be installed on a high-interaction honeynet for data collection. However, it is possible to use tools like Honeywall CDROM \footnote{https://projects.honeynet.org/honeywall/}, which is a bootable CDROM, to build a high-interaction honeypot very quickly.

There are many tools available on the website of The Honeynet Project \footnote{http://www.honeynet.org/tools}. These tools are mostly developed by the members of this project and they are used for different purposes, such as deployment of low-interaction honeypots, automated data analysis and malware collection. There are also some special-purpose tools for behavior analysis of some services and platforms, such as Win32 operating system family and android applications. The most well-known available tools other than the ones mentioned above are Cuckoo, Dionaea, HIHAT and Qebek.

As discussed above, low-interaction honeypots are easy to install and maintain. There is less risk in using them, because there is not an actual application behind them. However, the gathered information from low-interaction honeypots are very limited. Moreover, the honeypot software might itself have some vulnerabilities that would be a risk to the rest of the network \cite{Hoepers}.
 
High-interaction honeypots are harder to install and maintain. There is more risk in implementing a high-interaction honeynet, because the attacker has the full control over the honeypots. Moreover, it is very hard to deploy a large network of high-interaction honeypots, so honeynets are hard to scale. On the other hand, a high-interaction honeypot can gather more details about the attacker activities.

\subsection{Physical vs. Virtual Honeynets}

A physical honeynets is a group of high-interaction honeypots, in which each honeypot is running on a separate physical machine. Moreover, the data collection and data analysis components can run on separate physical machines. A virtual honeynet \cite{AbbasiHarris} \cite{HUZhenLi} uses virtualization technologies to implement multiple honeypots on top of a single hardware machine. In this case, all the honeypots are running on a single machine, but the attacker has the impression that he/she is interacting with different machines.

There are some advantages in using virtual honeynets: using a single machine instead of multiple honeypot machines, the cost will reduce significantly. Since everything resided in a single machine, another added value would be easier management. It is also a more secure approach, because the attacker is not interacting with the actual machines, so there is no harm in letting the honeypots be exploited.

To the best of our knowledge, the only research about offering honeypot as a service is done by M Balamurugan and B Sri Chitra Poornima \cite{HaaS}. They have proposed an architecture for implementation of a honeypot to be used besaide the services and systems running in a cloud environment. In this solution, all the traffic goes through the Cloud Controller. The Cloud Controller contains a a Filter and Redirection Engine (FRE), which acts similar to a Network Intrusion Detection System (NIDS). It redirects the malicious traffic destined to real servers towards the honeynet. The proposed model can be implemented and used for providing a honeynet service, but there are some disadvantages in using this approach:
\begin{itemize}
    \item It can just detect the attacks with a known signature inside the NIDS database
    \item It is possible that some non-malicious traffic being redirected to the honeynet without getting the real service
\end{itemize}

\section{Design}
\label{sec:design}

\subsection{The Ideal Features}

In this research, we are interested in offering an appropriate solution in order to provide honeynet service for different networks (including both physical networks and cloud environments). The offered solution is supposed to be able to solve the mentioned problems in the previous research done by M Balamurugan and B Sri Chitra Poornima \cite{HaaS}. In order to design a good model, it is necessary to specify the desired features and goals: First, it should satisfy the definition of the term ``service''. It means the provided service should be \cite{LIABook}:
\begin{itemize}
	\item reliable
    \item scalable
    \item easy to monitor, maintain and support
\end{itemize}
If this these fundamental requirements are not satisfied, we cannot call the final product a service. Then, the designed model should cover all the features of a honeynet \cite{Hoepers}. It means it should provide:
\begin{itemize}
	\item A controlled environment
	\item A high-interaction environment
	\item A data capture mechanism
    \item A data collection mechanism
    \item An alerting mechanism
\end{itemize}

The final goal is to get the best of both worlds: using real-systems (like high-interaction honeypots), but keep it simple, secure and scalable (like low-interaction honeypots).

\subsection{The Proposed Architecture}
After specifying the ideal features for a honeynet service, it is possible to come up with a model that covers these requirements, as much as possible. We assume that there is a customer network, interested in getting a honeynet as service, to become able to improve its security. The network owners should provide the Honeynet Service Provider (HSP) with some information via an interface and get a honeynet service easily and fast without difficulty or much effort.

If one wants to deploy a honeynet inside the customer's demilitarized zone (DMZ), a good approach is assigning some IP addresses from the range used in the customer's network to the honeynet. In case an attacker intrudes into the DMZ and starts scanning all the IP addresses to find the likely open ports, he/she faces the honeypots, but considers them as production servers. Then, the honeynet can capture the attacker activities and detect, analyze and report the findings to the network administrators. In our work, we are using a similar model. The main difference is that the honeynet is not inside the DMZ of customer, but it resides inside a cloud environment. The HSP assigns some honeypots to the customer based on the provided information. These honeypots are assigned from a pool of virtual machine instances inside the cloud. Therefore, the attacker traffic should be redirected towards the cloud.

In order to do the mentioned process, some fundamental components are needed. The proposed architecture in this research is consisted of the following components:

\subsubsection{The Fornt-end Component}
The fornt-end component is a user interface, which is the start point for using the service. This interface can be a simple web application. Using this interface, the customer lets the HSP know about the assigned IP addresses to the honeynet and also about the desired operating systems and applications to run on honeypot instances. Two different options can be offered about the the needed systems:
\begin{itemize}
    \item The customer can provide the specifications of the needed systems. 
    \item The customer can give the HSP an image to run on honeypot instances.
\end{itemize}
After getting this information,  the front-end component should initiate the requested VM instances as honeypots. In the proposed model, we also need a component for controlling the the redirected traffic toward the honeypots (also for controlling the reverse traffic originated from honeypots towards the customer's network), which we call it the ``monitor''. Upon receiving the service request from the customer, the front-end component should initiate a monitor. We will explain more about the monitor in section \ref{sec:monitor}.

\subsubsection{The redirecting component}
The redirecting component is a facility for forwarding the traffic destined to honeynet IP addresses towards the monitor component. The crucial expectation from this component is to keep the source and destination of packets unchanged. However, to be able to send the traffic to the monitor, we also need to use the IP address of the monitor as the destination. There are different solutions to redirect the traffic, while keeping the original source and destination addresses unmodified:
\begin{itemize}
	\item Iptables rules
    \item Switch configuration
    \item Virtual Private Network (VPN)
\end{itemize}

Configuring switches might be the most difficult solution, because it deals with confuting hardware from different vendors families. On the other hand, iptables can be a more general solution. The iptables rules can be added by running a simple script. 

\subsubsection{The honeypots}
As mentioned in section \ref{sec:highlow}, in order to have a honeynet, we need to use high-interaction honeypots. A high-interaction honeypot should simulate the behavior of the desired protocols. This goal can be best achieved using real applications and operating systems, which log all the attacker activities. In our architecture, each honeypot is a VM instance, initiated by the front-end, based on the received information from the customer. Each honeypot runs a specific application or operating system, with known vulnerabilities. Running the latest versions of applications and OSes can be useful in finding 0-day attacks.

Using VM instances, honeypots would be easier and cheaper to deploy. It is also easier and faster to recover the systems, in case of being exploited by an attacker.

\subsubsection{The monitor}
\label{sec:monitor}
The monitor is the core component in our architecture. It is a software module, which starts to run on top of a VM instance, upon reception of the service request from the customer. Therefore, we should have a monitor per each customer. However, different monitors can run on the same machine. It is worth mentioning that the suggested monitor component in this research in designed for detecting TCP attacks. The model can be improved to support both TCP and UDP attacks in a future work.

The monitor acts like a broker between the attacker and the honeypots. It is responsible to receive connections from the attacker (forwarded by the redirecting component) and establishing a connection to the proper honeypot. This can be done using the NetfilterQueue library in Python (or a similar library in another programming language). This library provides access to packets matched by an iptables rule in Linux \footnote{https://pypi.python.org/pypi/NetfilterQueue}. The monitor should get access to SYN packets to be able to open the right port to the attacker. Then, it can open another port to the appropriate honeypot, which is running a service matched by the opened port to the attacker. For example, if the attacker is trying to access port 80, the monitor establishes a connection to a honeypot running a web server application (which should be accessible via port 80).

One might suggest to use a simple proxy instead of the monitor, but it does not provide the desired functionality. Using a proxy, we have to change the source address in the arrived packets. If we do so, the honeypots do not know about the IP address of the attacker, so the attacker's IP detection process cannot be done properly.

After setting up the TCP connections, the attacker can communicate with the honeypots, but they are not directly connected. The monitor is in charge to exchange data between the two TCP connections. The benefit of this model is providing a controlled environment  All the traffic from an attacker just  can reach to the appropriate honeypot and the traffic from the honeypots can just go back to the monitor. Therefore, the attacker cannot directly access to a malware database from a honeypot to download a shellcode. If he/she decides to do so, the download request should be sent to the malware database via the monitor. Since this event is a suspicious activity, it can be considered as a malicious activity detection mechanism. After detecting and logging the malicious activity, the monitor can still let the attacker to exploit the honeypot to gather even more information about the motivation of the attack. Since the honeypot activities are controlled by the monitor, the honeypot cannot not be a threat to the outside world. In case of happening a serious problem for a honeypot, it can be easily rebooted and recovered.


\subsubsection{The Analysis Component}
Honeypots and also the monitor should regularly send their logs to an analysis component. This component is in charge of extracting summarized and informative reports about the network threats from the generated logs. The final results can be reported to the customer either directly or via the front-end component. A good option for this component would be using one or some of the available tools in the website of The Honeynet Project.

\subsection{Discussion}

The proposed architecture in this research satisfies the requirements of a honeynet service:
\begin{itemize}
    \item In case being implemented correctly, it is expected to be reliable
    \item It is scalable in terms of the number of customers. Since the monitor is initiated per customer, the monitor is not a single point-of-failure. Increasing the number of customers, we may need more VM instances for running the corresponding monitors, which is not a problem.
    \item It is geographically scalable, because no matter where the customers reside, the HSP can provide them with honeynet service
    \item It is easy to deploy and maintain for customers. They just need to provide some information via the front-end
    \item It is easy to deploy and maintain for the HSP. All the needed steps can be done automatically.
    \item It uses high-interaction honeypots, which run real applications and operating systems
    \item The suggested detection mechanism decreases the common security risks related to using high-interaction honeypots
    \item It is able to detect new attacks and capture malwares without signatures in the signature database
\end{itemize}

\section{Implementation}
\label{sec:implementation}

The following chapter explores in detail the test setup used during the latter phase of our project - implementation. The implemented code base can be found at the project's repository available at \url{http://goo.gl/GxLON}.

\subsection{General Overview}

In order to explore the implementational difficulties of providing honeynets as a service, Amazon Web Services (AWS) were used as a testbed. The main reason for choosing AWS over other open-source cloud technologies is the Infrastructure as a Service model which is already in place. AWS comes provisioned with robust virtualisation technologies and accompanying automation tools which allowed us to concentrate on the buildup of the underlying components for that given environment rather than the needed infrastructure. However, this can be also rendered by a custom-tailored solution that relies on own hardware in combination with software such as OpenStack and XEN.

\subsection{The setup}

A distinctive characteristic of the test setup is that the network traffic-handling components of the HaaS implementation expect to process only traffic originating from attackers destined towards the invalid resources (honeypots) in the user's network. The architecture relies on the fact that the distinction is made by the routing or firewall infrastructure part of the users's network. Handling of traffic towards valid user resources, such as their web-servers on the other hand remains a responsibility of the user.

Depicted in Fig.~\ref{fig:architecture_model} are the HaaS components required for servicing a single user of the service. 

\vspace{-.2cm}
\begin{figure}[h]
	\hspace*{-3.8cm}
	\includegraphics[width=5.9in]{../Figures/test_setup.png}
	\caption{Component overview for a single client}
	\label{fig:architecture_model}
\end{figure}
\vspace{1.0cm}

Users of the service would have as an entry point a Front-end component which can be perceived as a Web-based application. As it does not have a central role in the implementation of the service, the component is considered as part of future work on the project. The envisioned primary functionalities of the component should be:

\begin{itemize}
	\item User-identity tracking
	\item Forms for specifying the software stacks and network-based characteristics of honeypots
	\item Aggregated statistics generated by the logging mechanisms of honeypots
\end{itemize}
 

The back-end, depicted on the right-hand side of Fig.~\ref{fig:architecture_model}, is an always-on EC2-based instance that serves two distinctive purposes. While encapsulating the necessary functionalities that need to be provided to the front-end, it is also responsible for controlling the overall lifecycle of all other EC2-based virtual instances and their configuration. The direction of black arrows in the figure infers the type of inter-component communication that can occur.

The rest of the depicted EC2-based components - the monitor station, the Virtual Private Cloud (VPC) and the honeypot(s) part of it - are also dedicated to servicing a single user. 


\subsection{User traffic offloading}

In order to build the test setup various network models were considered, based on open-source technologies such as Linux IPv4/IPv6 forwarding and Iptables, so that the deployment and configuration effort users would have to perform are minimal. In addition, the implementation strives to minimize the utilization of the user's infrastructure by taking care of delivering return traffic to attackers without its involvement. However, the applicability of the service may vastly differ. Some users may wish to further secure their internal resources from breaches, whereas others their publicly accessible ones. In the former case users would deploy honeynets as part of their private network whereas in the latter at publicly accessible (routable) IP addresses.
The way users would have to set up traffic offloading within the two scenarios would be inevitably different. In order to prevent the disclosure of additional information on the location of honeynets, users would have to specify within the front-end web-forms the way they would achieve traffic offloading. An overview of considered traffic offloading options for the client follow:
\begin{itemize}
	\item Routing - In the case of routing additioinal information about the location of honeynets may be disclosed by the hop count filed part of network packets. If routing is to be used by clients, the monitor component would have to take care of modifying the relevant hop count field.
 	\item Forwarding - Any combination of PAT, DNAT and/or SNAT would obscure either the original source or destination address of packets which makes it impossible for the EC2-based honeynets to route traffic back to attackers. 
 	\item Proxying - A situation similar to forwarding would be created but only in terms of source addresses.
 	\item Tunneling - A situation similar to routing would be created but with the need of additional facilities on both sides for maintaining the tunnel.
\end{itemize}

Another concern with all considered traffic offloading techniques users may employ, is the fact that their infrastructure should not be burdened with facilities such as connection tracking. As connection tracking is a feature applied by default even for packets passing through netfilter's INPUT routing table, hints and best-practice information would have to be left within the front-end to specify the optimal ways for configuring the different types of traffic offloading.

As it is too restrivtive to force a single model upon users for traffic offloading, the test setup was build with traffic cloning on the users side so that packets retain their original source and destination addresses, do not undergo increments of their hop count field and are discarded by the users infrastructure before connection tracking occurs at the raw table of the INPUT chain.



\subsection{Back-end}

The back-end is represented by an always-on EC2 instance which serves two distinct purposes. First, it is responsible for processing requests originating from the front-end. Although the front-end insofar has been described as a Web-based application which in its meaning would require a Web-server and Web-based application code on the back-end side, instead the back-end provides plain Object-oriented Python class definitions with a main driver script for simulating the activities of a user in terms of starting and stopping honeynets. In addition, the back-end instance itself is an Ubuntu 12.04 system backed up to am AMI image which has two network adapters - one bound to an Elastic IP and the other to a VPC via which honeypots should ultimately send logged data.

In order to automate the processes of configuring, starting and stopping Amazon EC2 instances that represent monitor and honeypot nodes the AWS Python API was utilized. The features of the automation process cover are the following:

\begin{itemize}
	\item General:
	\begin{itemize}
		\item Amazon AWS region selection
		\item Types of instances to start
		\item Tracking groups of instance that belong to a single user - a tuple of monitor and honeypots
		\item Starting and stopping instances
		\item AWS security group settings
	\end{itemize}
	\item Monitor and honeypot-specific:
	\begin{itemize}
		\item Choosing associated AMI image
		\item Remote management access policies
		\item Network adapter(s)
		\item Network addressing
	\end{itemize}
\end{itemize}

The relevant classes representing the functionality as per the code base are Client Instance Manager TODO. The following limitation exist with the current model:
\begin{itemize}
	\item Users are not capable of picking a particular operating system and vulnerable software stack for their honeypots

	\item The back-end does not provide storage facilities for storing the various logging information generated by the honeypots
\end{itemize}


The second purpose of the back-end is to service the configuration requests of monitor nodes. Such requests seek out the IPs passed by users of the front-end which represent the IPs from their network at which the honeypots would be virtually placed. The requests themselves are handled via Python Pyro remote method invocations. The functionality has been encapsulated within a separate called Monitor RMI TODO. The class implements a single method that reads out the IPs specified by a user and sends them back to the monitor.



\subsection{Monitor}


The monitor is responsible for handing-off communication originating from the attackers of users resources to the appropriate honeypot. Contrary to the back-end, the monitor is a user-specific component of the service which is created upon the receipt of a user request. It is also based on an Ubuntu 12.04 system which was initially booted, configured and saved to an AMI image. The accompanying hand-off scripts were left within the root partition so that the they are merged with the image. The nature of the scripts however, is such that a certain level of initial configuration is required. As monitor nodes are responsible for handing communication off to the appropriate user honeypot based on the IP a users has assigned to the honeypot in their own network, their accompanying scripts need to obtain that mapping. The following general solutions were considered:

\begin{itemize}
	\item Creating a single EBS-based block device that stores the configuration of all monitor nodes.
	\item Creating an EBS-based block device for every monitor instance that contains its specific configuration
	\item Post-initialization configuration
\end{itemize}

Initially, considerations were made that a single, EBS-based storage container could be used for storing the configuration parameters needed by the different monitor nodes, however it is impossible to share EBS-based block devices between multiple EC2 instances. As an alternative, creating separate EBS-based block devices that hold the configuration of a single monitor was considered, however the solutions does not scale well in terms of the current Amazon EBS storage fees.\\
The second considered solution was to use post-initialization configuration for monitor nodes via either a distributed storage filesystem or a remote invocation procedure. The back-end is an acceptable node at which such a filesystem server could be initialized, however the flexibility of Python Remote Method Invocations was chosen instead as the best configuration method.


A python script controls the flow of network packets on the monitor. After system startup, the script's execution begins. As its first job it fetches the user-provided IP addresses in order to set up firewall rules for cloning packets.  One of the samples is sent to the script itself whereas the other to the appropriate honeypot. That way, monitor nodes can strictly regulate traffic destined towards honeypot and completely cut if off by removing firewall rules if needed. This behavior is achieved by using the iptables addon called xtables.

A limitation of the current test setup, which contradicts Fig.~\ref{fig:architecture_model}, is that the honeynets of users were not placed in private subnets, but were rather assigned Elastic IPs. This was done due to the high costs incurred by VPC clouds. However, the Amazon API was examined in order to establish that it is indeed possible to automate the creation and assignment of VPCs to EC2-based instanced. Within such a model, the networking of the monitor would also have to be change to a combination of NAT masquerade in combination with packet cloning.


\subsection{Honeypots}

Honeypots are also encapsulated into Amazon AMI images so that configuring and starting such instances is reduced to specifying an appropriate AMI. As network packets are passed to the honeypots with preserved source and destination addresses, destination NAT is performed upon receipt of packets destined towards any of the user-provided IPs by changing the destination to be the local IP address. That way, on their exit path packets are routed back to attackers via the honeypots themselves.



\section{Conclusion}
\label{sec:conclusion}
In this research, we were mainly concentrated on answering the following question: ``What is an appropriate architecture for providing honeynet as a service?''. To be able to answer this question, we described the ideal features of such a service. Then, we introduced the required components, including the front-end component, the traffic redirecting component, the monitor, the honeypots and the data analysis component. Then, we come up with a simple proof-of-concept implementation.

We also discussed how the proposed architecture provides various requirements of such a service. We concluded that the designed architecture is reliable, scalable, easy to deploy and maintain. The offered honeynets by this service are high-interaction, capable of detecting both normal and 0-day attacks and also not a threat to the rest of the network.

All in all, we conclude using the offered model, deployment of honeynets will become easier and cheaper. As a result, more and more networks will become able to utilize such a valuable security resource.


\section{Future Work}
In this research, we mostly focused on designing the appropriate architecture for offering a honeynet as a service. Although we come up with a simple proof-of-concept implementation, to be able to provide the real service, all the described components should be completely implemented according to the suggested architecture. The components which need more work are the monitor and the redirecting component.

The suggested architecture is proposed to deal with TCP attacks. To improve the research aspect, one can improve the monitor component to make it handle both TCP and UDP attacks.

Another improvement can be gained by designing a prediction module. This module can help in optimizing the number of needed VM instances (from each type of service) to be up and running at a certain time. This prediction can be done by discovering patterns in the incoming traffic towards the monitor. 

\newpage

\begin{thebibliography}{2}

\bibitem{Spitzner}
Spitzner, Lance. ``Honeypots: tracking hackers''. Addison-Wesley Longman Publishing Co., Inc., 2002.

\bibitem{Hoepers}
Hoepers, Cristine ,``Honeynets and Honeypots: Companion Technology for Detection and Response'', AusCERT2004 Conference, Technical Stream – May 24, 2004

\bibitem{survey}
Rammidi, Goaletsa. ``Survey on Current Honeynet Research'', A survey done in the honeynet project

\bibitem{AbbasiHarris}
Abbasi, Fahim H., and R. J. Harris. ``Experiences with a Generation III virtual Honeynet.'' Telecommunication Networks and Applications Conference (ATNAC), 2009.

\bibitem{HUZhenLi}
HU, Yi-zhao, Zhen WANG, and Li AN. ``Design and Realization of a Virtual Honeynet System'' Computer Engineering \& Science 8, 2009.

\bibitem{HaaS}
M Balamurugan , B Sri Chitra Poornima, ``Honeypot as a service in cloud'', International Conference on Web Services Computing , IJCA, 2012

\bibitem{LIABook}
Limoncelli, Thomas, Christina Hogan, and Strata Chalup. ``The practice of system and network administration'', Addison-Wesley Professional, 2007.

\bibitem{Bothunter}
Gu, Guofei, et al. ``Bothunter: Detecting malware infection through ids-driven dialog correlation.'' Proceedings of 16th USENIX Security Symposium on USENIX Security Symposium. USENIX Association, 2007.

\end{thebibliography}


\end{document}








